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Abstract 


A  new  approach  to  handling  battle  simulation  lethality  is  presented.  In  this 
approach,  a  single  vulnerability/lethality  server  provides  standard 
distributed  interactive  simulation  (DIS)  damage  states  to  entities  fast 
enough  for  most  real-time  applications.  Benefits  include  DIS  simulations 
being  freed  from  the  burden  of  maintaining  damage  state  tables  and  DIS 
exercises  being  easier  to  configure  as  a  whole.  A  DIS  software 
implementation  is  freely  available  by  contacting  the  author. 
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THE  DISTRIBUTED  INTERACTIVE  SIMULATION  (DIS)  LETHALITY 
COMMUNICATION  SERVER  VOLUME  1:  OVERVIEW 

1.  PURPOSE 

This  report  presents  an  overview  of  the  distributed  interactive  simulation  (DIS)  lethality 
communication  server  (the  server).  The  report’s  scope  is  focused  on  the  server’s  purpose, 
overall  design,  and  some  particular  features.  However,  this  text  cannot  be  used  to  effectively 
prepare,  operate,  or  modify  the  server.  (Refer  to  Volume  2  of  this  report  for  these  practical 
considerations.) 

2.  INTRODUCTION 

The  ARL  DIS  lethality  commtmication  server  is  a  combination  of  application  program 
interface  (API)  libraries  and  utility  programs  that  make  it  possible  to  allow  multiple  applications 
to  access  a  single  lethality  data  source.  The  server  is  designed  for  the  DIS  environment.  As  such, 
the  server  returns  lethality  results  as  described  by  (the  DIS)  Institute  of  Electrical  and  Electronics 
Engineers  (IEEE)  Standard  1278.1  [1]  Furthermore,  the  server  expects  input  in  DIS  standard 
protocol  data  unit  (PDU)  format,  although  the  equivalent  input  may  be  greatly  condensed  at  more 
abstracted  layers  within  the  APIs.  The  DIS  server  has  demonstrated  a  data  latency  of  less  than 
1/lOOth  of  a  second  and  thus  may  be  useful  for  a  wide  variety  of  applications.  This  project  was 
jointly  sponsored  by  the  U.S.  Army  Modeling  &  Simulation  Office  (as  a  1997  Army  Modeling 
Improvement  Program  [AMIP]  project)  and  by  the  U.S.  Army  Research  Laboratory  (ARL). 

3.  OBJECTIVE 

The  motivation  for  the  server  stemmed  jfrom  the  author’s  experiences  in  conducting  DIS 
exercises  among  different  types  of  simulations.  A  frastrating  problem  was  to  discover  “holes”  in 
one  or  another  simulation’s  lethality  data  set.  Naturally,  different  simulations  handled  this 
situation  differently.  This  resulted  in  “unfair”  play  between  simulators  (or  occasionally,  a  fatal 
error  in  a  simulator).  Until  the  problem  could  be  fixed  (and  the  lethality  holes  “plugged”),  the 
impact  on  the  DIS  exercise  was  usually  catastrophic.  Thus,  the  original  objective  of  the  server 
was  to  alleviate  this  situation  and  thereby  increase  the  amount  of  “free  play  flexibility”  and 
decrease  the  amount  of  overall  pre-exercise  preparation.  After  a  little  thought,  it  became  evident 
that  there  are  several  serendipitous  benefits  to  having  a  lethality  server: 
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•  The  server  could  eliminate  DIS  interoperability  variances  in  lethality  results  (remove 
“unfair”  weapons  effects  play),  since  all  DIS  simulations  will  resolve  lethality  effects 
through  a  single,  repeatable  means. 

•  It  would  allow  increased  ease  of  verification,  validation,  and  accreditation  (VV&A)  for 
battle  simulations  exercises  as  a  result  of  having  a  standard  (and  centralized)  set  of 
imclassified  lethality  calculations. 

•  It  could  decrease  DIS  simulation  development  time  by  providing  a  completed,  computer 
platform-generic,  lethality/vulnerability-handling  mechanism.  That  is,  because  the  lethality 
issue  has  been  decoupled  from  the  rest  of  the  simulation,  the  lethality-handling  mechanisms 
may  be  “stubbed  out,”  allowing  more  time  to  devote  to  the  rest  of  the  simulation 
development  process. 

4.  LIMITATIONS 

Every  automated  system  must  have  design  trade-offs  and  performance  limitations.  This 
section  mentions  two  of  the  most  important. 

4.1  Limitation  on  Environmental  Awareness 

There  is  currently  no  provision  for  making  the  server  aware  of  the  synthetic  environment 
(terrain).  The  server’s  knowledge  of  what  and  where  things  are  is  limited  to  the  DIS  network 
traffic.  Therefore,  only  distance  and  orientation  from  the  point  of  detonation  are  considered  for 
area  (indirect)  detonations  against  a  platform.  External  influences  that  may  affect  the  outcome  (e.g., 
walls,  earth,  etc.)  are  not  considered  since  the  lethality  server  will  have  no  knowledge  of  them. 

4.2  Data  Latency 

The  DIS  server  should  be  acceptably  fast  for  real  time,  training,  and  most  other  applications. 
Informal  tests  demonstrate  the  server’s  response  time  to  be  faster  than  normal  human  reaction 
speed.  Naturally,  data  latency  depends  on  computer  processing  speeds,  network  bandwidth,  and 
network  traffic.  The  informal  tests  were  conducted  with  an  unoptimizedl  server  compilation 

*  No  special  considerations  were  made  to  “tweak”  the  server  or  client  programs;  they  were  compiled  without 
optimization.  Furthermore,  both  the  DIS  server  and  the  client  application  output  verbose  “debugging”  information 
during  this  test.  Therefore,  these  results  could  be  viewed  as  a  data  latency  upper  boundary  for  these  processors  over 
a  standard  10-mbps  (millions  of  bits  per  second)  Ethernet. 


across  a  populated  network  during  “normal  business  hours.”  Figure  1  shows  the  distribution  of 
time  taken  to  send  (and  receive  the  answer  to)  440  separate  server  queries.  For  these  tests,  the 
average  data  latency  was  about  6  microseconds  (p-sec),  but  a  very  few  tests  (about  0.7%  of  the 
queries)  took  much  longer  (between  20  and  30  psec). 


Data  Latency  During  DIS  PDU  Network  Traffic 


Time  (seconds) 


Figure  1.  PIS  Server  Response  Latency. 


The  DIS  exercise  included  79  DIS  entities  (67  tanks,  10  infantry  fighting  vehicles,  and  2 
mobile  anti-aircraft  platforms).  Together,  they  generated  20,281  PDUs  during  a  heavy  16-mmute 
battle.  This  took  place  across  a  standard  10base2  (thin  Ethernet)  network  that  was  not  dedicated 
to  the  DIS  server.  That  is,  other  data  beside  the  server’s  queries  and  the  DIS  PDUs  also 
competed  for  network  bandwidth.  Approximately  98  other  network  hosts  (other  computers, 
printers,  etc.)  resided  on  the  same  network  and  produced  normal  imiform  data  protocol  (UDP) 
and  transmission  control  protocol/intemet  protocol  (TCP/IP)  traffic  on  the  network,  although  an 
unknown  number  were  probably  inactive  at  the  time.  The  DIS  server  (and  the  client  application) 
resided  on  Silicon  Graphics  Incorporated  (SGI)  Indigo2  computers  that  used  150-MHz  R4400 
processors. 

5.  DESIGN 

First  and  foremost,  from  an  implementation  point  of  view,  the  server  is  designed  to  be 
expandable.  Many  extensions  can  be  accomplished  by  manipulating  system  parameters  and 
initialization  data.  Other  enhancements  require  additional  software.  For  example,  an  unsupported 
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vulnerability  data  format  may  be  accommodated  by  adding  two  functions  to  a  software  library . 
(More  of  these  details  are  discussed  in  Section  6.) 

At  the  most  general  point  of  view,  the  server  is  a  system  designed  to  provide  “data,”  based 
on  some  criterion.  Currently,  the  criterion  is  focused  on  DIS  battlefield  “munition”  type  events. 
However,  the  server  may  be  expanded  to  include  other  criteria.  The  data  that  the  server  provides 
are  given  somewhere  in  a  local  (to  the  server)  file  (or  potentially  at  a  remote  site).  The 
appropriate  data  are  delivered  to  the  client  upon  request. 

Operationally,  the  server  is  designed  be  flexible  to  meet  the  needs  of  client  applications  by 
allowing  networked  or  non-networked  use.  In  network  mode,  clients  communicate  with  the 
server  via  (a  standard  and  platform- independent  protocol)  TCP/IP  sockets.  Optionally,  the 
server  can  be  implemented  as  a  callable  subroutine  (inside  the  client  application)  with  no  external 
networking  traffic  necessary.  This  allows  flexibility  for  the  client.  The  network  connection  will 
be  slightly  slower;  however,  its  use  shall  ensure  that  all  exercise  participants  using  it  are  accessing 
the  same  lethality  data  sets.  These  two  communication  configurations  are  explained  now. 

5.1  Callable  Snhrmitine  Inside  the  Simulation  (fastest  communication  speed) 

In  this  schema  (shown  in  Figure  4),  data  relating  to  the  vulnerable  platform  and  the 
threatening  munition  are  a  binary  stream  representing  standard  DIS  PDUs.  This  information  is 
passed  directly  to  the  server  via  an  API  function  call.  The  server  returns  the  lethality  result  (the 
damage  state  occurring  against  the  threatened  entity  platform  as  a  result  of  the  munition 
detonation  or  other  event). 

5.2  Networked  Server.  With  DIS  Traffic  Monitored 

In  this  topology  (shown  in  Figure  3),  the  server  monitors  DIS  PDU  traffic  on  the  UDP  DIS 
network.  Communication  with  client  occurs  via  TCP/IP  sockets.  The  client  requests  the  result 
from  a  detonation  event  by  referencing  the  identifier  (ID)  for  the  detonation  event  and  the  ID  of 
the  threatened  entity.  These  IDs  are  part  of  the  DIS  standard,  and  because  the  server  is 
monitoring  the  DIS  traffic,  it  knows  which  type  of  platform  is  referred  to  by  the  entity  ID.  The 
server  also  monitors  other  data  that  were  broadcast  on  the  DIS  network  and  are  relevant  to  a 
vulnerability  calculation.  The  server  then  returns  the  result  to  the  client  via  the  TCP/IP  network 
link. 


Originally,  a  third  topology  was  planned  as  shown  in  Figure  2. 
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DIS  Network  Traffic 


Client 

TCP/IP 

Server 

network 

Figure  2.  Networked  Server.  DIS  Traffic  Not  Monitored  (unimplemented). 


This  topology  differs  from  Figure  3  in  that  the  server  would  have  no  prior  knowledge  of 
detonations  or  entities.  In  this  case,  the  client  would  be  required  to  send  more  detailed  information 
concerning  the  event.  This  topology  was  proposed  as  a  building  block  before  the  topology  of 
Figure  3  was  achieved.  However,  once  the  server’s  capability  to  monitor  DIS  network  traffic  was 
completed,  it  made  no  sense  to  implement  this  topology  for  the  reasons  stated  below. 


DIS  Network  Traffic 


Client 

TCP/IP 

Server 

network 

Figure  3.  Networked  Server  Topology. 


a.  In  the  topology  of  Figure  4,  the  data  required  by  the  server  would  be  delivered  in  the 
form  of  DIS  PDUs.  These  very  same  PDUs  were  already  broadcast  on  the  DIS  network.  With 
the  capability  to  monitor  DIS  PDUs  completed  (Figure  3),  it  is  unnecessary  for  the  client  to 
resend  them  (since  the  server  has  been  monitoring  the  network  and  already  has  these  PDUs). 

b.  If  the  client  wishes  to  simulate  a  DIS  exercise  by  sending  complete  PDUs,  this  may  be 
done  by  using  the  topology  of  Figure  4. 
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DIS  Network  Traffic 


[Tli 

ent 

(Server  is  a  non-networked 
subroutine  to  the  client.) 


Server 


Figure  4.  Non-Network  Server  Topology. 


6.  FEATURES  AND  EXPANDABILITY 

This  section  highlights  features  and  outlines  the  type  of  expandability  that  is  built  into  the 
server’s  design  at  the  time  of  this  writing. 

6.1  Criteria  for  Determining  Which  Data  are  Delivered 

The  server  needs  to  know  which  type  of  data  a  client  application  wishes  to  retrieve.  This 
is  accomplished  in  two  steps.  The  first  step  is  to  associate  the  data  with  a  “threat”  and  “target.” 
These  data  describe  a  target-threat  interaction  of  a  certain  lethality  “class.”  The  second  step 
involves  monitoring  the  battlefield  for  the  triggering  event. 

Currently,  the  server  only  handles  one  type  of  triggering  event,  namely,  “munition”/ 
“detonation”  type  threats  against  an  entity.  There  is  no  provision  for  damage  resulting  firom 
collisions,  biological/chemical  exposure,  or  other  kinds  of  damage  mechanisms.  However,  the  server 
is  expandable  and  there  is  no  reason  why  these  (and  other  means  of  damage  assessment)  may  not 
be  added.  However,  this  would  require  additional  code  to  make  the  server  “look  for”  and  process 
the  particular  battlefield  events  that  the  lethality  result  depends  upon  (see  Section  6.2). 

It  was  mentioned  that  the  target-threat  interaction  is  a  certain  lethality  “class.”  This  class 
identifier  allows  the  server  to  respond  differently  for  different  situations.  As  an  illustration, 
suppose  the  data  source  for  a  ballistic  munition  divides  lethality  results  according  to  dispersion  at 
impact  time.  Without  a  lethality  class,  the  server  will  return  the  lethality  result  from  that  data 
source  even  if  the  munition  (was  close  but)  missed  the  target.  On  the  other  hand,  if  the  server 
knows  that  this  munition-target  interaction  is  of  the  “direct  fire  hit-to-kill”  class,  then  it  will 
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correctly  bypass  the  data  source  and  return  a  “no  further  damage”  result  (since  the  munition 
missed).  This  flexibility  allows  the  server  to  be  expanded  to  other  lethality  classes  as  they 
develop.  There  are  currently  only  two  lethality  classes  (“indirect  fire”  and  “direct  fire  hit  to  kill”). 

6.2  Criteria  for  Determining  Lethal  Parameters 

Knowing  how  to  behave  for  certain  “lethality  classes”  is  not  enough.  The  server  also  needs 
to  know  upon  what  environmental  factors  and  initial  conditions  the  lethality  calculation  depends. 
The  server  accomplishes  this  by  using  the  “lethality  class”  identifier  to  associate  which  parameters 
are  important  to  that  particular  type  of  lethality  result.  Currently,  the  server  only  handles  one  type 
of  triggering  event— that  of  “munition”/ “detonation”  type  threats,  of  which,  direct  and  indirect  fire 
munitions  are  sub-categories.  These  threats  are  characterized  by  an  explosion  or  explosive/ 
nonexplosive  ballistic  impact.  The  server  knows  which  environmental  parameters  are  necessary  to 
complete  the  lethality  calculation  for  these  types  of  threats.  Specifically,  the  server  tracks  the 
appropriate  DIS  PDUs  and  extracts  the  required  environmental  parameters  from  them. 

In  the  DIS  environment,  the  simulation  that  controls  such  a  direct  or  indirect  fire  munition 
announces  the  munition’s  explosion  or  impact  by  broadcasting  a  detonation  PDU  to  all  the 
exercise  participants.  Any  munition  that  can  be  simulated  in  this  manner  can  currently  be 
serviced  by  the  server.  A  provision  of  this  is  that  the  resulting  damage  to  a  threatened  entity 
would  then  occur  as  a  relatively  immediate  reaction  to  the  detonation  as  opposed  to  one  requiring 
prolonged  exposure  to  a  damage-inflicting  environment  (such  as  a  dust  storm,  forest  fire,  noxious 
gas,  etc.).  This  is  because  the  lethality  server  does  not  account  for  damage  as  a  function  of  time 
for  these  lethality  classes.  It  merely  returns  lethality  data  based  on  an  event  (a  denotation). 

These  returned  data  are  then  used  by  the  client  in  an  appropriate  manner.  [2]  The  server  does  not 
continue  to  monitor  the  environment  for  “continued  degradation”  resulting  from  prolonged 
exposure.  This  type  of  behavior  couldht  added  by  creating  a  new  “lethality  class.”  Naturally,  it 
would  also  require  adding  new  behavior  code  to  the  server  for  that  class. 

One  exception  to  the  immediate  lethality  reaction  just  mentioned  is  that  the  server  maintains 
a  record  of  the  number  of  munition  “hits”  occurring  against  any  entity.  While  this  information  is 
available  for  clients  to  use  as  they  see  fit,  it  is  not  currently  used  by  the  server  to  assess  damage. 
Furthermore,  current  APIs  do  not  distinguish  which  types  of  munition  accounted  for  the  various 
hits;  however,  all  this  information  is  maintained  by  the  DIS  monitor  module,  and  a  summary 
output  of  all  munitions  and  their  effects  is  output  in  a  report  file  (called  rollup,  det). 


7 


6.3  Returned  Results 


6.3.1  Types  of  Vulnerability  Methods  (Results) 

When  a  lethality  event  occurs,  many  results  are  possible.  Analysts  usually  divide  the 
number  of  “end  states”  into  more  manageable  sets.  We  refer  to  a  set  of  possible  outcomes  as  the 
vulnerability  methodology.  The  only  criterion  is  that  the  outcome  sets  describe  the  complete 
universe  of  possible  outcomes.  A  simple  example  would  be  a  binary  methodology  (“dead”  or 
“alive”  states).  Most  often,  it  is  useful  to  have  a  more  detailed  division  of  outcomes.  The  server 
is  designed  to  accommodate  a  variety  of  “kinds”  of  vulnerability  methodologies. 

6. 3. 1.1  One  Implemented  Vulnerability  Methodology  (the  MFK  class) 

While  the  server  is  designed  to  accommodate  a  variety  of  vulnerability  methods,  as  of 
this  writing,  only  one  methodology  is  implemented.  This  methodology  conforms  to  DIS  standard 
terms  that  describe  the  damage  state  of  an  entity.  (Specifically,  lethality  results  are  a  subset  of 
damage  “states”  in  the  DIS  entity  state  appearance  field.)  This  methodology  divides  lethality 
results  in  terms  of  mobility,  fire  power,  and  catastrophic  “kills”  (MFK).  Expanding  the  server  to 
handle  other  methodologies  would  require  adding  another  probability  (result)  classes  in  addition  to 
MFK,  along  with  APIs  to  support  them.  (Volume  2  of  this  report  explains  how  this  may  be  done.) 

6.3.1 .2  A  Variety  of  Answers  for  Each  Vulnerability  Methodology 

Within  the  context  of  a  vulnerability  method,  effects  may  be  returned  in  a  variety  of 
formats,  depending  on  the  form  that  the  query  takes  (or  which  API  is  called).  In  addition  to  (or 
instead  of)  returning  the  results,  the  server  can  return  the  raw  probabilities  and  let  the  client 
decide  how  to  use  them.  For  example,  the  client  may  query  what  is  the  probability  that  no 
significant  damage  occurred  (a  single  probability),  or  the  client  may  query  what  is  the  probability 
of  each  of  the  possible  outcomes  occurring  (multiple  probabilities).  However,  it  is  recommended 
that  for  DIS  battle  simulations,  clients  should  request  the  results  (and  not  the  probability  of  a 
result  occurring).  In  this  manner,  the  probabilities  are  organized  and  the  same  random  number 
generator  is  used  by  every  client. 

As  concerns  the  one  implemented  vulnerability  methodology  (MFK),  if  a  client 
requests  an  MFK  lethality  result  (as  opposed  to  the  probability  of  a  result),  the  answer  will  be 
one  and  only  one  of  the  items  listed  in  Table  1 . 
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Table  1.  MFK  “Probability”  Space 


Explanation 

MKILL 

Mobility  and  only  mobility  kill. 

FKILL 

Firepower  and  only  firepower  kill. 

MFKILL 

Both  mobility  and  firepower  kills. 

KXILL 

Catastrophic  kill. 

NoDamage 

No  additional  damage  inflicted. 

The  results  in  Table  1  describe  the  universe  of  all  possible  outcomes  under  the  MFK  methodology. 

Along  with  each  of  the  results,  a  flag  will  be  returned,  which  informs  the  client  if  an 
actual  lethality  data  source  was  used  to  determine  the  weapon  effects.  The  only  reason  that  a 
source  would  not  be  used  is  because  it  was  not  found  by  the  server  (because  it  did  not  exist)  or 
because  it  was  inaccessible  (by  the  server).  In  either  case,  when  a  valid  lethality  source  cannot  be 
accessed,  then  the  result  is  generated  from  a  random  draw  of  a  single  fixed  (invalid)  distribution. 

In  the  case  of  MFK,  this  distribution  is  portrayed  in  Figure  5. 

0.5 

£.0.4 

lo-3 

S0,2 

CL 

0,1 
0 

Figure  5.  Default  Results  (when  a  valid  lethality  data  source  is  not  available). 


Current  Fixed  (default)  MFK  Distribution 


KILL  KILL  KILL  KILL  Dmg 


In  this  way,  the  server  can  guarantee  that  all  data  ‘‘holes”  are  filled.^  Also,  all  clients  will  know 
when  they  are  receiving  results  from  an  (invalid)  default  distribution. 


^This  distribution  is  maintained  in  the  API  function  VL_mfkDis_ResultGen0rlcRandomDraw()  and  may 
be  modified  there.  See  Volume  2  of  this  report  for  details  (Appendix  B,  vl(3)). 
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6.3.2  Look-up  Table 

The  server  returns  damage  results  found  by  accessing  “look-up”  tables.  At  least  one  data 
file  is  associated  with  each  target-threat  combination.  (However,  the  same  file  may  be  used  for 
any  number  of  targets  and  threats.)  Cuirently,  these  files  must  be  accessed  within  the  file  system 
of  the  host  computer,  but  the  server  may  be  relatively  easily  extended  to  add  remote  file  access. 
This  is  because  files  are  specified  by  a  uniform  resource  locator  (URL).  Thus,  a  natural  extension 
is  to  allow  look-up  table  file  access  over  a  network  by  a  number  of  protocols  (http,  gopher,  ftp, 
etc.).  Naturally,  proper  security  measures  must  be  maintained  if  any  of  these  data  are  classified. 

Currently,  the  server  only  implements  local  file  access  fe.g..  /7/g:///tmp/filel23.dat)  and  will 
return  an  error  if  a  datum  source  is  specified  as  a  remote  host.  URL  access  is  serviced  by 
employing  a  tiny  subset  of  the  Libwww  (a  general  purpose  web  API  provided  by  the  World  Wide 
Web  Consortium).  Therefore,  expanding  the  capability  of  the  server  (by  adding  more  functionality 
to  the  Libwww)  should  be  relatively  easy.  The  current  (and  final  version  of  Libwww)  is  available 
at  URL  address  http://www.w3  .org/Librarv. 

Once  further  development  is  made  to  allow  for  other  types  of  URL  access,  the  server  would 
not  be  limited  to  just  static  “look-up”  tables.  The  URL  could  reference  another  database  server 
with  queries,  or  even  another  application  that  could  return  calculations  “on  the  fly”  firom  higher 
fidelity  vulnerability/lethality  models.  ARL’s  Survivability/Lethality  Analysis  Directorate 
(SLAD)  has  an  ongoing  project  to  make  models  available  for  “on-the-fly”  analysis  in  the  future. 
However,  it  is  unclear  what  form  the  “front-end”  server  for  this  capability  will  assume  at  this  time. 

6.4  Beyond  PIS 

While  numerous  server  components  are  tailored  to  the  DIS  environment,  the  server  or 
portions  of  the  server  could  be  expanded  for  use  in  other  environments.  This  is  allowed  by  the 
layered  design  of  the  server.  For  example,  an  HLA^  “front  end”  may  be  added  to  the  server 
simply  by  changing  one  component  (the  DIS  monitor  component)  to  listen  to  “HLA”  traffic 
instead  of  “DIS”  traffic.  In  the  language  of  HLA,  the  server’s  clients  would  become  “federates” 
which  “subscribed”  to  the  server’s  “published”  lethality  results.  The  appendix  explains  in  a  little 
more  detail  the  division  of  the  components  and  the  services  each  provides.  (Another  HLA 
compatibility  option  would  be  to  leave  the  server  as  a  “DIS  only”  tool  and  insert  a  translation 


^  The  U.S.  Department  of  Defense  high  level  architecture  (HLA);  first  release  specification  was  in  August  1996. 
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utility  on  the  network  such  as  the  HLA  Gateway^.)  This  tool  translates  relevant  HLA  network 
traffic  into  DIS  traffic  (PDUs).  Reference  [3]  suggests  some  possible  approaches  toward  HLA 
migration. 

7.  SUMMARY 

A  DIS  lethality  server  has  been  implemented.  It  has  the  potential  to  eliminate  differences  in 
how  lethality  effects  are  treated  and  to  remove  variances  in  which  data  sources  are  used  among 
DIS  exercise  participants.  This  supports  a  tighter  and  more  easily  handled  DIS  exercise 
configuration  management  (since  all  lethality  sources  of  a  distributed  exercise  are  handled  in  a 
single  location)  and  conforms  to  recommended  standards  [4]. 

The  server  is  designed  to  be  flexible  and  expandable.  Detailed  examples  of  how  to  expand  it 
are  presented  in  Volume  2. 

The  server  can  increase  the  ease  and  amount  of  DIS  exercise  “free  play”  flexibility  and  can 
decrease  the  amount  of  overall  pre-exercise  preparation. 


^  Developed  at  the  Institute  for  Simulation  and  Training,  Orlando,  Florida 
(http://www.ist.ucf.edu/labsproj/projects/hgprode.htm). 
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DIS  LETHALITY  SERVER  ARCHITECTURE 


Figure  A-1  displays  a  view  of  the  server’s  architectural  design.  Boxes  enclosed  by  solid 
lines  represent  independent  processes.  Each  of  these  processes  may  be  run  on  separate 
computers.  The  one  exception  is  the  DIS  Server  and  DIS  Monitor;  these  two  processes  must 
reside  on  the  same  host  machine,  as  indicated  by  the  dotted  box.  Dashed  lines  separating  the  VL 
API  and  Data  Manager  indicate  that  these  represent  DIS  server  service  layers  (APIs)  which 
must  reside  within  a  parent  process. 


DIS  Network  Traffic 


Figure  A-1.  DIS  Server  Architecture. 


The  architecture  layout  seen  in  Figure  A-1  is  a  more  detailed  depiction  of  the  networking 
topology  shown  in  Figure  3.  The  clients’  connectivity  to  the  DIS  network  is  not  shown.  To 
connect  to  the  DIS  network,  clients  may  choose  to  use  the  ARL  DIS  Manager  (which  is  freely 
provided  with  the  lethality  server),  use  a  commercially  available  product  (such  as  VR  Link®),  or 
their  own  in-house  DIS  networking  library.  It  is  not  the  responsibility  or  within  the  scope  of  the 
lethality  server  to  decide  how  clients  prefer  to  connect  to  the  DIS  network. 
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An  explanation  of  the  components  follows: 

•  The  ARL  DIS  Manager  monitors  DIS  PDUs  and  sends  them  to  its  own  clients.  In  this 
case,  the  DIS  manager  has  one  client  (the  DIS  Monitor).  Because  the  DIS  monitor  currently 
only  is  concerned  with  MFK  vulnerability,  it  only  requests  to  receive  entity  state,  fire,  and 
detonation  PDUs  (since  these  are  the  only  PDUs  necessary  to  calculate  MFK  results).  The 
DIS  monitor  may  request  other  PDU  types  from  the  DIS  manager  as  necessary. 

•  The  DIS  Monitor  monitors  all  fire/detonation  events  (along  with  information  concerning 
any  entities  involved).  It  maintains  cached  records  of  these  events.  In  this  way,  the 
parameters  involved  will  be  available  when  the  DIS  Server  queries  it  for  the  results  of  a 
particular  detonation. 

•  Upon  receipt  of  a  query  from  the  DIS  server,  the  DIS  monitor  calls  the  VL  AlPI  which  sets 
the  appropriate  parameters  that  describe  the  conditions  at  the  time  of  the  detonation  (e.g., 
munition  type,  velocity,  etc.).  The  VL  API  then  calls  the  Data  Manager  API  which 
provides  data.  The  VL  API  layer  then  returns  these  data  in  a  format  appropriate  to  query. 

•  The  Data  Manager  API  manages  many  types  of  low  level  data.  It  maintains  records  of 
where  to  find  data  sources  for  each  entity  and  threatening  mumtion.  It  keeps  track  of  which 
functions  are  used  to  read  each  type  of  data  source  into  memory  and  (once  read)  which 
function  to  use  to  find  results  in  the  cached  memory  data  structures.  It  is  also  responsible  for 
maintaining  which  DIS  enumerations  are  used  to  describe  a  particular  vehicle,  munition,  or 
other  item. 

•  The  job  of  the  DIS  Server  component  is  relatively  simple.  This  component  merely  passes 
client  queries  to  the  DIS  Monitor  and  returns  the  DIS  monitor’s  results  to  the  client.  This 
raises  the  question,  why  is  the  DIS  server  component  necessaiy?  There  are  several  benefits 
to  using  a  networked  approach.  First,  it  allows  a  “fair  fight”  if  all  clients  are  assured  they  are 
receiving  data  from  the  same  source  and  in  the  same  manner.  Second,  W&A  of  the 
simulation  exercise  is  made  easier  since  only  one  lethality  data  set  needs  to  be  checked. 
Simulation  development  time  might  be  decreased.  These  points  were  made  in  Section  3. 

Despite  these  advantages,  some  applications  may  find  it  beneficial  (for  speed  or  other 
reasons)  to  use  a  non-networked  server  architecture  (and  thereby  bypass  the  DIS  Server 
component).  The  server’s  modular  design  allows  this.  All  that  is  necessary  is  for  the  application 
to  use  the  API  calls  directly.  Doing  so  will  tremendously  reduce  data  latency.  The  drawback  is 
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that  the  application  will  have  to  handle  many  of  the  bookkeeping  services  provided  by  the  DIS 
monitor,  as  well  as  provide  its  own  interface  to  the  DIS  traffic.^  Figure  A-2  displays  the 
architectural  layout  of  this  approach. 


DIS  Network  Traffic 


Single  Host  Computer 


Figure  A-2.  Non-Networked  Connection  to  DIS  Server  APIs. 

Figure  A-2  is  a  more  detailed  version  of  the  topology  seen  in  Figure  4.  Here,  the  client  is 
responsible  for  monitoring  the  DIS  network  traffic  and  passing  to  the  VL  API  the  appropriate 
parameters.  The  parameters  passed  to  the  API  functions  would  be  in  the  form  of  PDUs. 


^Although  as  mentioned,  the  ARL  DIS  Manager  may  be  used  to  connect  to  the  DIS  network  if  the  user  so  desires. 
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